Thank you all for these results and observations.
It's hard to know how the CPU usage is really being affected by the prediction. I will look and see if I can add a CPU usage timer that can display CPU usage for Physics and Prediction separately. If I could make this visible on screen at the side, then we could get more of an idea how badly Turn One mayhem is affected by increased packet rate in conjunction with high ping.
The other thing is a prediction issue that seems worst with the BF1. I don't think it's anything unique about the BF1 - it's probably just the most extreme example. I get the feeling that it is not only related to speed. I think it may be something to do with tyre deflection. Suspension deflection is included in the position packet but lateral tyre deflection is not. So I think for the first frame of prediction, forces on the car are too small and it takes a couple of updates to build up the tyre forces. It's only a theory. Unfortunately it would need a larger position packet and that can't be done in a compatible version but I'll have a look. We want to do an incompatible version anyway but we're a few days from that as there are still compatible updates to do. Anyway I can test locally at first.
I think we also need an option to watch MPRs without the steering smoothing, so it's a better representation of what we see online. Don't know if I could add a bad ping simulation to it as well.
That's a good observation. For some reason which I can't remember, the program does an estimate of when the next packet will arrive. U13 uses the U13 next packet time calculation so that explains why the U12 ones move too quickly then stop. I'm not sure why it was easier to do it that way rather than using a real packet time.
It's hard to know how the CPU usage is really being affected by the prediction. I will look and see if I can add a CPU usage timer that can display CPU usage for Physics and Prediction separately. If I could make this visible on screen at the side, then we could get more of an idea how badly Turn One mayhem is affected by increased packet rate in conjunction with high ping.
The other thing is a prediction issue that seems worst with the BF1. I don't think it's anything unique about the BF1 - it's probably just the most extreme example. I get the feeling that it is not only related to speed. I think it may be something to do with tyre deflection. Suspension deflection is included in the position packet but lateral tyre deflection is not. So I think for the first frame of prediction, forces on the car are too small and it takes a couple of updates to build up the tyre forces. It's only a theory. Unfortunately it would need a larger position packet and that can't be done in a compatible version but I'll have a look. We want to do an incompatible version anyway but we're a few days from that as there are still compatible updates to do. Anyway I can test locally at first.
I think we also need an option to watch MPRs without the steering smoothing, so it's a better representation of what we see online. Don't know if I could add a bad ping simulation to it as well.
That's a good observation. For some reason which I can't remember, the program does an estimate of when the next packet will arrive. U13 uses the U13 next packet time calculation so that explains why the U12 ones move too quickly then stop. I'm not sure why it was easier to do it that way rather than using a real packet time.
Thanks, maybe you can suggest they try the U13 test patch if possible?
Most benefits will come from the use of the patch.
DCon only allows the max pps up to 12 but most of the time that doesn't affect anything.
Most benefits will come from the use of the patch.
DCon only allows the max pps up to 12 but most of the time that doesn't affect anything.
How it works is: Any MPR stores all the network packets that are sent (as long as they are received).
So if there is a good connection, an MPR stored on player A's computer should look identical to the MPR stored on player B's computer. As you can see in kagurazakayukari's video, the MPR from both computers is mostly identical, other than a few points where some packets got lost.
So you can actually test the effect of the packet rate by saving an MPR locally.
But there are two things different in an MPR:
- In an MPR, prediction time is only the time between two packets. Live online prediction time is the time between two packets plus the delay between the packet being sent on the driver's PC and received on the observer's PC.
- In an MPR, inputs can be smoothed between one packet and the next which helps make the prediction a bit better.
No, that's not how it works.
Well I released a patch yesterday that should have improved that quite a bit for people with good ping. I haven't had a lot of feedback about the results yet.
EDIT: That's not a complaint - it's not an easy thing to test so may take time. And the person who downloads the test patch isn't the one who will see the results. It's the other people who should see their car glitching less. Best results are when driver and observer both have the new version, because the steering glitch reduction is at both ends (that is a separate feature from the extra packets).
One possible test would be to observe two people with equally good ping, driving on a flat surface, maybe slaloming gently left to right in sync with each other, in the same car. One driver has U13 and the other driver has U12 or earlier. The observer should have the new version. The result of the test should be visible in the MPR.
Actually there doesn't really need to be a live observer, only the two drivers. The 'observer' could be anyone who watches the MPR later.
Last edited by Scawen, .
The Wizard DK: I've moved your posts about shifting to a new thread in technical assistance because it's not related to the test patch.
https://www.lfs.net/forum/thread/94955
https://www.lfs.net/forum/thread/94955
Did you get those messages with the previous version of LFS, or only with the test patch?
Test Patch U13 is available.
It's intended as a moderate improvement. I have tried to increase packet frequency carefully where it is needed, while making sure it is never decreased. The idea is to reduce glitching but without causing the negative effects that could come from packet overload.
I'm not saying it's perfect or the best it can be, but I believe it is noticeably better, after 1.5 days' work.
Where I say "sender" below I mean the local computer where a car is being driven. When I say "receiver" I mean someone observing that car on a remote computer.
Multiplayer:
Reduced steering glitch each time a position packet is received
- this requires the sender and receiver to have the new version
Position packets are sent more frequently in response to steering
- packet frequency is further increased at higher speeds
- this requires only the sender to have the new version
Maximum packets per second (/pps) has been increased to 12
- this doesn't change much except in specific circumstances
- FIX: /pps command while in multiplayer was not sent to guests
- this requires only the server to have the new version
https://www.lfs.net/forum/thread/93185
It's intended as a moderate improvement. I have tried to increase packet frequency carefully where it is needed, while making sure it is never decreased. The idea is to reduce glitching but without causing the negative effects that could come from packet overload.
I'm not saying it's perfect or the best it can be, but I believe it is noticeably better, after 1.5 days' work.
Where I say "sender" below I mean the local computer where a car is being driven. When I say "receiver" I mean someone observing that car on a remote computer.
Multiplayer:
Reduced steering glitch each time a position packet is received
- this requires the sender and receiver to have the new version
Position packets are sent more frequently in response to steering
- packet frequency is further increased at higher speeds
- this requires only the sender to have the new version
Maximum packets per second (/pps) has been increased to 12
- this doesn't change much except in specific circumstances
- FIX: /pps command while in multiplayer was not sent to guests
- this requires only the server to have the new version
https://www.lfs.net/forum/thread/93185
Test Patch U13 is available.
It's intended as a moderate improvement. I have tried to increase packet frequency carefully where it is needed, while making sure it is never decreased. The idea is to reduce glitching but without causing the negative effects that could come from packet overload.
I'm not saying it's perfect or the best it can be, but I believe it is noticeably better, after 1.5 days' work.
Where I say "sender" below I mean the local computer where a car is being driven. When I say "receiver" I mean someone observing that car on a remote computer.
Multiplayer:
Reduced steering glitch each time a position packet is received
- this requires the sender and receiver to have the new version
Position packets are sent more frequently in response to steering
- packet frequency is further increased at higher speeds
- this requires only the sender to have the new version
Maximum packets per second (/pps) has been increased to 12
- this doesn't change much except in specific circumstances
- FIX: /pps command while in multiplayer was not sent to guests
- this requires only the server to have the new version
https://www.lfs.net/forum/thread/93185
It's intended as a moderate improvement. I have tried to increase packet frequency carefully where it is needed, while making sure it is never decreased. The idea is to reduce glitching but without causing the negative effects that could come from packet overload.
I'm not saying it's perfect or the best it can be, but I believe it is noticeably better, after 1.5 days' work.
Where I say "sender" below I mean the local computer where a car is being driven. When I say "receiver" I mean someone observing that car on a remote computer.
Multiplayer:
Reduced steering glitch each time a position packet is received
- this requires the sender and receiver to have the new version
Position packets are sent more frequently in response to steering
- packet frequency is further increased at higher speeds
- this requires only the sender to have the new version
Maximum packets per second (/pps) has been increased to 12
- this doesn't change much except in specific circumstances
- FIX: /pps command while in multiplayer was not sent to guests
- this requires only the server to have the new version
https://www.lfs.net/forum/thread/93185
Last edited by Scawen, .
If anyone would like more information about the current work on prediction and packet frequency, here are a few posts on the test patch thread.
https://www.lfs.net/forum/post/1961950#post1961950
https://www.lfs.net/forum/post/1961950#post1961950
Thanks for the reference video but the rest of your post is basically antagonistic, irritating and factually incorrect.
Maybe you've missed the updates in the test patch thread.
This is not about 'pps' as I keep saying but it goes over the head of people all the time. The issues involved are far more subtle.
Petrol makes cars go, right? So if my car is broken I can pour petrol over it to fix it, right? No, that is wrong. So dear people, please stop saying that more and more packets per second will solve everything. It won't.
Also, MicroSpec, I'm here working all yesterday and today looking into how to improve the predictions. So telling me my code is 'trash' because you have a terrible ping is not helpful. Also your advice that we shouldn't be prioritising tyre choices is entirely irrelevant, because that is something you've made up, and has nothing to do with what is actually happening.
A small update 'U13' for the dedicated host (DCon) is attached.
It allows /pps 12 in internet multiplayer mode.
I don't think it makes much difference, as it is only an upper limit on "position packets per second" but in some situations it could help. It will *not* cure the problems of latency and can make some problems resulting from latency even worse (namely CPU usage on your local computer during the 'catch up' from when the packet was sent on the remote computer, to the current time).
The previous maximum was 6.
The command /pps X was found not to be working to change pps while already running but it does now work and there is a message on guest computers when the resulting packet is received.
This is a compatible update.
EDIT: removed attachment, it's now the official test patch.
It allows /pps 12 in internet multiplayer mode.
I don't think it makes much difference, as it is only an upper limit on "position packets per second" but in some situations it could help. It will *not* cure the problems of latency and can make some problems resulting from latency even worse (namely CPU usage on your local computer during the 'catch up' from when the packet was sent on the remote computer, to the current time).
The previous maximum was 6.
The command /pps X was found not to be working to change pps while already running but it does now work and there is a message on guest computers when the resulting packet is received.
This is a compatible update.
EDIT: removed attachment, it's now the official test patch.
Last edited by Scawen, .
Thanks for the feedback.
I was wondering about this often requested change. As usual I fear it may make things worse. I believe it can help when all players are near the server, with minimal lag. In this case it can bring similar benefits to using a high pps on a LAN. The problem I have with it is that the really bad lagging you see is usually from players with high latency (time lag to the server).
Higher pps cannot help with this. Such players, if sending twice as many packets per second, will not appear any better to the other players and will still be all over the place. Only now they will consume more CPU on the other players' computers because of the catch-up physics done on each position update.
So the problem is that more packets per second cannot possibly solve the worst problem and could make it worse. Turn 1 slowdowns could become a slide show of carnage.
I feel it's a bit like having a broken cylinder head gasket and increasing the turbo boost to try to get some more power to compensate.
But I can see that it could be worth a test. Maybe I can even run a local multiplayer test here using a remote server to get an initial feel for it before trying it in public.
Good question, I'll need to ask Victor about this.
Other comments - thanks for the feedback. I'm reading and thinking...
I was wondering about this often requested change. As usual I fear it may make things worse. I believe it can help when all players are near the server, with minimal lag. In this case it can bring similar benefits to using a high pps on a LAN. The problem I have with it is that the really bad lagging you see is usually from players with high latency (time lag to the server).
Higher pps cannot help with this. Such players, if sending twice as many packets per second, will not appear any better to the other players and will still be all over the place. Only now they will consume more CPU on the other players' computers because of the catch-up physics done on each position update.
So the problem is that more packets per second cannot possibly solve the worst problem and could make it worse. Turn 1 slowdowns could become a slide show of carnage.
I feel it's a bit like having a broken cylinder head gasket and increasing the turbo boost to try to get some more power to compensate.
But I can see that it could be worth a test. Maybe I can even run a local multiplayer test here using a remote server to get an initial feel for it before trying it in public.
Good question, I'll need to ask Victor about this.
Other comments - thanks for the feedback. I'm reading and thinking...
Possible changes for a semi-compatible update
NOTE: This is about a quick update of the existing version. Nothing to do with the major changes in the development version.
Hello Racers,
A test patch has been in use for a long time and some people would like it to become official.
I would like to ask about a few small changes which are easy and safe to introduce, but would make the version incompatible online. So if they are done, they should be tested for the minimum time before becoming official.
I've been asked a few times about increasing the number of AI per player in multiplayer mode. This is easily done but I'm not that confident to allow the full number of 32 drivers per connection. I feel it's better to test in smaller steps but in this case maybe we could go up a lot from the current maximum of 3. How about to 24?
Some other changes have been requested, for the use of GTR cars for drifting and off-road.
Drifters have asked for the maximum steering lock to be increased and to allow the full range of tyres, for the XRR and FZR cars. We received a request to allow up to 65 degrees steering angle but it seems a bit much to me. Those two cars have double wishbone suspension so that seems to put a limit on the amount a wheel could turn before part of the wheel hits part of a wishbone with disastrous results. I don't have any real world reference for what maximum lock is achievable by drifters in real life.
About off-road use, I found a note from about 10 years ago suggesting to allow the off road tyres on the smaller GTR cars as they have some resemblance to rallycross cars and that could allow some fun racing. I've seen a recent request to allow the FXO GTR to use the off road tyres for rallycross.
So, combining the above two purposes it seems like it could be a good idea to allow the knobbly, hybrid, road and road super tyres on all the GTR cars, and to increase the allowed maximum lock on the XRR and FZR.
Reservations:
It might be a bit unrealistic, allowing such tyres on those cars. The big GTR cars are obviousy not designed for off road use, but if it allows more possibilities for drifting and racing, then it seems like a good thing to allow.
Steering lock being increased a lot, with wide front wheels on double wishbone suspension, might seem to defy reality a bit. But I'm interested to hear what you have to say.
P.S. What I mean by "semi-compatible" is that old hotlaps should still be valid if these lock and tyre choice limits were relaxed. But this new version could not connect with the old version online.
Hello Racers,
A test patch has been in use for a long time and some people would like it to become official.
I would like to ask about a few small changes which are easy and safe to introduce, but would make the version incompatible online. So if they are done, they should be tested for the minimum time before becoming official.
I've been asked a few times about increasing the number of AI per player in multiplayer mode. This is easily done but I'm not that confident to allow the full number of 32 drivers per connection. I feel it's better to test in smaller steps but in this case maybe we could go up a lot from the current maximum of 3. How about to 24?
Some other changes have been requested, for the use of GTR cars for drifting and off-road.
Drifters have asked for the maximum steering lock to be increased and to allow the full range of tyres, for the XRR and FZR cars. We received a request to allow up to 65 degrees steering angle but it seems a bit much to me. Those two cars have double wishbone suspension so that seems to put a limit on the amount a wheel could turn before part of the wheel hits part of a wishbone with disastrous results. I don't have any real world reference for what maximum lock is achievable by drifters in real life.
About off-road use, I found a note from about 10 years ago suggesting to allow the off road tyres on the smaller GTR cars as they have some resemblance to rallycross cars and that could allow some fun racing. I've seen a recent request to allow the FXO GTR to use the off road tyres for rallycross.
So, combining the above two purposes it seems like it could be a good idea to allow the knobbly, hybrid, road and road super tyres on all the GTR cars, and to increase the allowed maximum lock on the XRR and FZR.
Reservations:
It might be a bit unrealistic, allowing such tyres on those cars. The big GTR cars are obviousy not designed for off road use, but if it allows more possibilities for drifting and racing, then it seems like a good thing to allow.
Steering lock being increased a lot, with wide front wheels on double wishbone suspension, might seem to defy reality a bit. But I'm interested to hear what you have to say.
P.S. What I mean by "semi-compatible" is that old hotlaps should still be valid if these lock and tyre choice limits were relaxed. But this new version could not connect with the old version online.
The same fix should be in 6U and any patch since. The LFSOpenVR.dll in 6U has a file date of 8 March 2019 which is only shortly after the one linked 3 posts up. It should give the same results. There shouldn't be any relevant changes in the U12 version that would affect this.
I don't think anyone else has mentioned the HP Reverb except for Ross Burton in this post on the Test Patch thread:
https://www.lfs.net/forum/post/1952241#post1952241
In his case it seems to work well (although his post was before the latest version of the dll). I'd be interested to have a look in the openvr.log file if you attach it here. Sometimes there can be a clue in there. It appears in the LFS folder when you use an OpenVR headset.
EDIT: I see Ross Burton was using the old HP Reverb, not the G2 so it seems you are the first to comment about this headset.
I don't think anyone else has mentioned the HP Reverb except for Ross Burton in this post on the Test Patch thread:
https://www.lfs.net/forum/post/1952241#post1952241
In his case it seems to work well (although his post was before the latest version of the dll). I'd be interested to have a look in the openvr.log file if you attach it here. Sometimes there can be a clue in there. It appears in the LFS folder when you use an OpenVR headset.
EDIT: I see Ross Burton was using the old HP Reverb, not the G2 so it seems you are the first to comment about this headset.
Last edited by Scawen, .
Hi, sorry but that is not possible at the moment, as there can only be 3 drivers per computer. So with two computers that is a maximum of one real driver plus 5 AI.
I do have a note for the request to allow more cars per computer as it has been requested a few times. I don't think it is really difficult but it would be an incompatible version as changes are needed on guest and host side.
I'm considering the possibility of a new incompatible version with this change and also a small change to allow more maximum lock on FZR and XRR for drifters.
The problem with incompatible updates is they divide the community between official version users and test patch users so it's important to keep those testing stages as short as possible.
Also I have to keep such updates as safe and minimal as possible because there is so much work to do on the separate development version.
I do have a note for the request to allow more cars per computer as it has been requested a few times. I don't think it is really difficult but it would be an incompatible version as changes are needed on guest and host side.
I'm considering the possibility of a new incompatible version with this change and also a small change to allow more maximum lock on FZR and XRR for drifters.
The problem with incompatible updates is they divide the community between official version users and test patch users so it's important to keep those testing stages as short as possible.
Also I have to keep such updates as safe and minimal as possible because there is so much work to do on the separate development version.
Thank you for the test results!
Sorry I didn't answer your questions in October. I remember seeing your post and thought I should answer but didn't make a note to remind myself to do so.
Sorry I didn't answer your questions in October. I remember seeing your post and thought I should answer but didn't make a note to remind myself to do so.
Test Patch U12 is now available and this problem should be fixed. https://www.lfs.net/forum/thread/93185
Downloads should be a bit faster too.
That is interesting because it seems you can recreate the skin issue on your system.
I'd be interested to know if U12 fixes that for you.
Downloads should be a bit faster too.
That is interesting because it seems you can recreate the skin issue on your system.
I'd be interested to know if U12 fixes that for you.
No. It would be test patch U11 + bug fix.
It's very mysterious so far.
k_badam says he is using the latest test patch. I guess it's not related to the test patch, because it has been going fine since April without any problem. But to confirm that, are any of you getting the same fault with the official version?
Of course the code is designed so that there is a timeout if packets stop arriving.
The screenshot posted by Degats might be a clue. The negative number might indicate corruption (perhaps by a buffer overrun) or an unexpected way through the code.
Degats, would it be possible to share that replay? (Or anyone else who got that problem when starting a replay). If the same thing happens when I try to start the replay then I should be able to catch it. If this is reproducible by any means then I'm sure I'll be able to catch it.
To my mind, something has changed on the server. Otherwise how could copies of LFS develop a bug, several months after release? But of course LFS should not hang or become corrupted, whatever packets the server sends.
I enabled logging with the /log command. There's an http header line I don't remember: ETag: "4a6318a5-a5ac"
I don't know what that means but I'll have a look at how LFS deals with those header lines. At first sight it looks as if it simply ignores lines it doesn't recognise.
One last question, do you think it would be worth disabling skin downloads while we figure this out? If the bug often prevents people joining servers, that is worse than not seeing skins. I can temporarily stop skin downloads with a setting on the master server.
k_badam says he is using the latest test patch. I guess it's not related to the test patch, because it has been going fine since April without any problem. But to confirm that, are any of you getting the same fault with the official version?
Of course the code is designed so that there is a timeout if packets stop arriving.
The screenshot posted by Degats might be a clue. The negative number might indicate corruption (perhaps by a buffer overrun) or an unexpected way through the code.
Degats, would it be possible to share that replay? (Or anyone else who got that problem when starting a replay). If the same thing happens when I try to start the replay then I should be able to catch it. If this is reproducible by any means then I'm sure I'll be able to catch it.
To my mind, something has changed on the server. Otherwise how could copies of LFS develop a bug, several months after release? But of course LFS should not hang or become corrupted, whatever packets the server sends.
I enabled logging with the /log command. There's an http header line I don't remember: ETag: "4a6318a5-a5ac"
I don't know what that means but I'll have a look at how LFS deals with those header lines. At first sight it looks as if it simply ignores lines it doesn't recognise.
One last question, do you think it would be worth disabling skin downloads while we figure this out? If the bug often prevents people joining servers, that is worse than not seeing skins. I can temporarily stop skin downloads with a setting on the master server.
Last edited by Scawen, .
Reason : corrected wrong user name
Thank you all for the comments!
I was just testing some lighting updates at the autocross area and was driving around in the LX4 in the dark, when I came across the skid pad and started to test out what we were talking about. I drove around well within the grip limits and did some gentle applications of the throttle.
It turns out that it behaved as you said after all, the front did take a wider line with extra throttle.
This was in an LX4 with an open diff and with matching front and rear wheels.
I haven't had a close look at the forces going on, or done any comparisons with other cars. But just wanted to confirm that my original statement was too general or (maybe completely wrong) and that your statement was a very good point.
Nice to see you, Ben.
Yes I still have the E46 M3 and it still has low mileage! It will be 18 next year.
I was just testing some lighting updates at the autocross area and was driving around in the LX4 in the dark, when I came across the skid pad and started to test out what we were talking about. I drove around well within the grip limits and did some gentle applications of the throttle.
It turns out that it behaved as you said after all, the front did take a wider line with extra throttle.
This was in an LX4 with an open diff and with matching front and rear wheels.I haven't had a close look at the forces going on, or done any comparisons with other cars. But just wanted to confirm that my original statement was too general or (maybe completely wrong) and that your statement was a very good point.
Nice to see you, Ben.
Yes I still have the E46 M3 and it still has low mileage! It will be 18 next year.
I don't have time to get into tyre physics at the moment but had some thoughts on it after Eeekie's post.
I think there are some competing effects when the throttle is applied.
1) As Eeekie described, the rear wheels become more loaded, lengthening the contact patch and so requiring less slip angle for a given lateral force. And conversely the front wheels become less loaded, get a shorter contact patch and require more slip angle for a given lateral force. From this point of view the car might take a wider line without any steering adjustment.
2) But there is another effect and that is that a wheel which has a longitudinal force applied, will produce less lateral force for a given slip angle. So from this point of view, a rear wheel drive car with more throttle applied (and no change in steering input) will follow a tighter line because the rear wheels will require a wider slip angle for a given force.
3) There are also other possible competing effects, such as the change in toe and camber due to suspension deflection, and the effect of a limited slip differential.
Now, I definitely may be wrong but I imagine number (2) above to be the dominant effect. I think that is how it is in my car but it would be hard to test unless I can find a skid pad. It may well be that a different effect is dominant in different cars, due to the different mass distributions and other design features. As I apply the throttle there is a whole range of slip angles before the point when the whole contact patch is skidding. Now I'm really not a crazy driver at all these days and don't drive much anyway but there are times when I can accelerate pretty hard out of a roundabout without any danger to myself or others. I can apply a lot of power without actually going sideways and it feels to me like it gets closer to oversteer through that process. It feels very planted and poised as I apply more power. A good part of my mind is focussed on the rear wheels, remembering I used to be a motorcyclist and am very aware of going over the limit. It's a feeling of confidence though and there is a certain joy to it. I believe I get this same feeling in the new physics of LFS, but in the old LFS there are some slight changes of line that don't seem to correspond with reality.
I think there are some competing effects when the throttle is applied.
1) As Eeekie described, the rear wheels become more loaded, lengthening the contact patch and so requiring less slip angle for a given lateral force. And conversely the front wheels become less loaded, get a shorter contact patch and require more slip angle for a given lateral force. From this point of view the car might take a wider line without any steering adjustment.
2) But there is another effect and that is that a wheel which has a longitudinal force applied, will produce less lateral force for a given slip angle. So from this point of view, a rear wheel drive car with more throttle applied (and no change in steering input) will follow a tighter line because the rear wheels will require a wider slip angle for a given force.
3) There are also other possible competing effects, such as the change in toe and camber due to suspension deflection, and the effect of a limited slip differential.
Now, I definitely may be wrong but I imagine number (2) above to be the dominant effect. I think that is how it is in my car but it would be hard to test unless I can find a skid pad. It may well be that a different effect is dominant in different cars, due to the different mass distributions and other design features. As I apply the throttle there is a whole range of slip angles before the point when the whole contact patch is skidding. Now I'm really not a crazy driver at all these days and don't drive much anyway but there are times when I can accelerate pretty hard out of a roundabout without any danger to myself or others. I can apply a lot of power without actually going sideways and it feels to me like it gets closer to oversteer through that process. It feels very planted and poised as I apply more power. A good part of my mind is focussed on the rear wheels, remembering I used to be a motorcyclist and am very aware of going over the limit. It's a feeling of confidence though and there is a certain joy to it. I believe I get this same feeling in the new physics of LFS, but in the old LFS there are some slight changes of line that don't seem to correspond with reality.
Calculations and algorithms based on models and then the constants adjusted to try to match test rig data available for some tyres, and lateral force figures for some cars and just sometimes we can do lap time comparisons.
So in short - get a benchmark based on models and constants then adjust the constants according to as many real world results as possible.
In practice you can then find the models or assumptions are wrong or don't scale properly then you can read scientific papers on theory of rubber adhesion, etc. and try to figure out how to make sense of such complex phenomena described in seemingly abstract papers with confusing mathematics, into something that can really be implemented into realtime simulation with several cars at the same time.
So in short - get a benchmark based on models and constants then adjust the constants according to as many real world results as possible.
In practice you can then find the models or assumptions are wrong or don't scale properly then you can read scientific papers on theory of rubber adhesion, etc. and try to figure out how to make sense of such complex phenomena described in seemingly abstract papers with confusing mathematics, into something that can really be implemented into realtime simulation with several cars at the same time.
Yes this would be helpful for maintaining high frame rate as the CPU still has do do a lot of work asking the graphics card to draw things. So I will be thinking about this probably when I'm on the physics.
I did have to use 11 because InterlockedAdd was not allowed in feature level 10 and I couldn't think of another way to add to the histogram buffer.
Some possibilities here, the old 'read back a small texture and analyse on CPU' is still there for test purposes, so could be resurrected for Direct3D 10 GPUs. But I was thinking maybe feature level 10 could use the SDR mode and use time-based exposure instead. That would allow D3D10 graphics cards to use LFS but some things wouldn't be much good, e.g. it would be very dark in a car park.
But I don't know how many people have a Direct3D 10 graphics card as D3D10 was out a relatively short time before D3D11 was available. I think for now I'll keep trying to make sure it can run on them using SDR.
The new tyre physics is in this new version. So the situation is that it might be a bit hard to try to copy the old tyre physics from the public version, into this new version. I am more motivated to try and update the new tyre physics to an acceptable level. It is nice to drive with but needs some good work on load sensitivity, pressure and temperatures which are not correct.
Yes, I found in VR the exposure is calculated as dark if you use the whole view, because so much of the view is the car interior, so then it overexposed the image. So in LFS it limits the exposure check to a smaller square in each eye (both added together for a single exposure histogram). This limited square is 30 degrees each way, equivalent to a 60 degree FOV on a square monitor.
Is this something to do with the test patch?
It's not clear what you are saying.
Test Patch U11 is now available with a minor improvement for VR and you can now control the strength of the Horizon Lock.
Changes from 0.6U9 to 0.6U11:
VR:
- Using latest update for OpenVR
- Improved timing of obtaining view each frame
Views:
- Horizon lock now has a strength slider option
Small improvement for ultrawide monitors:
- LFS now assumes 3 screens when aspect ratio is 4:1
- previously assumed 3 screens when aspect ratio was 3:1
Some more updated translations - thank you translators!
DOWNLOAD: https://www.lfs.net/forum/thread/93185
Changes from 0.6U9 to 0.6U11:
VR:
- Using latest update for OpenVR
- Improved timing of obtaining view each frame
Views:
- Horizon lock now has a strength slider option
Small improvement for ultrawide monitors:
- LFS now assumes 3 screens when aspect ratio is 4:1
- previously assumed 3 screens when aspect ratio was 3:1
Some more updated translations - thank you translators!
DOWNLOAD: https://www.lfs.net/forum/thread/93185
FGED GREDG RDFGDR GSFDG